Security concerns for all types of processor-based electronic devices, and particularly for computing devices, have become a significant concern. While some concerns may relate to detrimental actions which may be undertaken by defective code implemented by such devices, the greater concerns relate to the ramifications of various types of attacks made upon such devices through malicious code, including code conventionally known in the field by a number of names, including “viruses”, “worms”, “Trojan horses”, “spyware”, “adware”, and others. Such malicious code can have effects ranging from relatively benign, such as displaying messages on a screen, or taking control of limited functions of a device; to highly destructive, such as taking complete control of a device, running processes, transmitting and/or deleting files, etc. Virtually any type of imaginable action on a processor-based device has been the subject of attacks by malicious code.
Many of these attacks are labeled at computing devices, such as processor-based systems such as workstations, servers, desktop computers, notebook and handheld computers, and other similar devices. Many of these computing devices can run one or more application programs (“applications”) which a user may operate to perform a set of desired functions. However, such attacks are not limited to such computing devices. A broader group of various types of processor-based devices (or “processor devices”), such as cell phones; personal digital assistants (“PDA's”); music and video players; network routers, switches or bridges; and other devices utilizing a microprocessor, microcontroller, or a digital signal processor (in addition to computing devices, discussed separately above), to execute coded instructions have been the subjects of attacks by malicious code. A number of methodologies have been used in an attempt to reduce or eliminate both the attacks and influence of malicious or defective code. Generally, these methodologies include detection, prevention, and mitigation. Specifically, these methodologies range from attempts to scan, identify, isolate, and possibly delete malicious code before it is introduced to the system or before it does harm (such as is the objective of anti-virus software, and the like), to restricting or containing the actions which may be taken by processes affected by malicious or defective code.
One such containment system, implemented on a UNIX system, is a system known as Systrace. The Systrace system is described in the publication: “Improving Host Security With System Call Policy”, by Niels Provos, Center for Information Technology Integration, University of Michigan, Nov. 11, 2002. The Systrace system seeks to establish a containment policy for an application by intercepting all system calls made by the application at a high level, specifically at the transition into the kernel layer of a computer operating system, such as at the system call application program interface (“API”) level. Once a system call is identified at such interface, the call is compared to an established policy identifying calls that the application should need to make in order to perform its intended functions. If the system call seeks to take an action which is not one which the application would normally need to take, as determined by the established system policy, then the action will not be permitted.
The Systrace containment system, however, suffers from some disadvantages, a few of which are the following. One such disadvantage is that not all actions pass through the system call API interface. Thus, it is possible that actions may be initiated in the kernel that are not monitored by Systrace. Additionally, intercepting system calls at this high level does not allow the consideration of as much information regarding the system calls as would be desirable for a system to make an optimally “informed” decision. Further, because the system calls are intercepted as they enter the kernel, it is possible that as to any specific system call, there may be a difference in the propriety of the call dependent upon what calls may have preceded the call in question. The Systrace system does not track changing context from one system call to another, so may not properly filter some system calls (like those that operate on a file descriptor rather than filename).
Accordingly, it would be desirable to have a system which intercepts operations in the kernel before they execute, and preferably implementing such operation interception after the arguments for such operations are at least partially identified.